Networked computer systems, and particularly the Internet, have revolutionized the handling of financial transactions over the past few decades. For example, a consumer can purchase goods and services on an on-demand basis via websites hosted by providers of such goods and services. The consumer can also automatically make periodic bill payments and transfer funds between accounts via online mechanisms. The consumer can also purchase and play games via online mechanisms. There are many more such applications, and the number of such applications continues to grow at a fast pace.
However, the development of online transaction handling mechanisms has also introduced complexity. As an illustration of this point, consider FIG. 1. FIG. 1 shows an online environment 100 that accommodates a plurality of transaction handling systems (A, B, . . . n). Transaction handling system A includes processing functionality 102 coupled to a data store 104. Transaction handling system B includes processing functionality 106 coupled to a data store 108. Transaction handling system n includes processing functionality 110 coupled to a data store 112. One of many consumers (consumer A) can interact with any of the transaction handling systems (A, B, . . . n) through a device A 114 via an online coupling mechanism (not shown).
Each of the transaction handling systems (A, B, . . . n) is separate from the others. Namely, each of the transaction handling systems (A, B, . . . n) can use different infrastructure, and each of the transaction handling systems (A, B, . . . n) can apply different rules and protocols which govern the handling of transactions. For example, transaction handling system A can permit a consumer to make purchases in excess of an amount of available funds in the consumer's account (thus incurring a debt), while transaction handling system B can prohibit a consumer from incurring a debt. These different systems may therefore provide distinct functionality and rules for handling these two different scenarios. This is merely an example of the many types of transaction handling systems in use today that are designed to serve specific roles. Other systems provide distinct functionality and methodology that is specifically tailored for particular use environments (e.g., a gaming environment, a media download environment, etc.). Other systems provide distinct functionality and methodology that apply to different jurisdictions (e.g., countries), and so forth.
This approach introduces various complexities and inefficiencies. For example, the provider of such systems (A, B, . . . n) might find that these systems do not scale well. That is, because these systems (A, B, . . . n) were developed to serve specific needs, it is difficult to modify these systems to serve other needs. It is true that one special-purpose system can enter into a contractual agreement with another special-purpose system to provide a combined aggregate service. But this implementation is also inefficient and does not scale well, and may be prohibitive from an economical standpoint (because a partner system may charge fees for its services on a per-transaction basis that become prohibitively expensive). Further, the use of independent systems is inefficient because it requires a brute force duplication of processing functionality.
From the user experience standpoint, a consumer is tasked with the responsibility of gaining familiarity with many different systems (A, B, . . . n). This may pose difficulties, as each of these systems (A, B, . . . n) may provide different kinds of interfaces that use different protocols, styles, and so forth.
Another difficultly arises when it is necessary to transfer finds-related resources from one system to another. Since each system uses different infrastructure and methodologies, such conversions may represent a complex task, which may be time-consuming and subject to error.
For at least the above-identified reasons, there is an exemplary need for more satisfactory strategies for handling transactions.